feat(cli): load plugin configs from plugin.toml - #93

Overview

• I confirm this contribution is my own work, or I have the right to submit it under this project's license.
• I searched existing issues and open pull requests, and this does not duplicate existing work.

Details

Summary

This PR wires the CLI gateway to the generic NeMo Flow plugin configuration path and adds a dedicated plugin.toml file option for process-level plugin activation.

The gateway now resolves a single PluginConfig from supported configuration sources, activates it when the server starts, and clears it when the server shuts down. The implementation is generic over plugin kind; the tests exercise the observability plugin today while keeping the config path usable for future plugin kinds such as adaptive once those plugins are registered in the CLI process.

Changes

• Add daemon-mode --plugin-config / NEMO_FLOW_PLUGIN_CONFIG support.
• Add plugin.toml discovery and loading for root-level generic PluginConfig TOML.
• Resolve plugin.toml alongside explicit --config path/to/config.toml.
• Discover implicit plugin.toml files from system, nearest project, and user scopes.
• Reject conflicting plugin definitions across plugin.toml, [plugins].config, and --plugin-config.
• Preserve existing [plugins].config support in config.toml.
• Document the CLI gateway plugin.toml shape for observability plugin configuration.

Validation

cargo fmt --check
cargo test -p nemo-flow-cli
cargo build -p nemo-flow-cli

Notes

• plugin.toml uses the generic plugin config shape at the file root:

version = 1

[[components]]
kind = "observability"
enabled = true

[components.config]
version = 1

• This PR covers observability configuration only in examples/tests.
• Adaptive remains out of scope for this PR, but the resolver is intentionally plugin-kind agnostic.

Where should the reviewer start?

Start with crates/cli/src/config.rs. The key design decision is that the CLI still resolves exactly one generic PluginConfig, but that config may now come from --plugin-config, [plugins].config, or plugin.toml. The conflict checks in that file are the main behavior to review.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Closes #

Summary by CodeRabbit

• New Features

  • Add CLI/env --plugin-config support with startup activation of a single process-level plugin configuration, discovery/precedence of plugin.toml, and daemon-mode triggering via the flag.
  • Plugin initialization and teardown tied to server lifetime.

• Bug Fixes

  • Improved validation, conflict detection and user-facing error reporting for plugin configuration sources and merges.

• Documentation

  • New CLI gateway plugin configuration docs with examples, precedence, merge semantics, and validation notes.

• Tests

  • Expanded integration and coverage tests for discovery, precedence, validation, and server behavior.